\documentclass[14pt]{article}
% 
% Packages used:
%
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsfonts}
\usepackage{fleqn}
\usepackage{amsthm}
\usepackage[cp1251]{inputenc}
\usepackage{fullpage}

\author{Valeria Nikolaenko and Kevin Lewi}
\title{CS255. Project 1. Milestone 2.}

\begin{document}
\marginparsep = 10pt
\maketitle

\section{Build a MAC system based on AES}
Since we want to provide integrity together with confidentiality, we are using 
the construction that was described in class for the IPsec protocol: first 
encrypt, and then apply the MAC scheme. This construction was said to be secure 
in class.

So firstly, we compute the cipher of the message $c \leftarrow E(K_{enc}, m)$ 
(already done in Milestone1) and then compute a MAC signature on that cipher 
$MAC \leftarrow S(K_{MAC}, c)$. We implemented the CBC-MAC scheme, built on top 
of AES which we used as a PRP.

Generally speaking to be sure that our scheme provides integrity together with 
confidentiality, we need to use independently chosen distinct random keys for 
encryption and MACing. Note that for ECBC-MAC we need two distinct independent 
keys.

We achive this by producing keys in the following way from our original key $K$, 
where $K$ is either a group key or a database key:

\begin{align*}
&K_{enc} = AES(K, 0) || AES(K, 1)\\
&K_{MAC}^1 = AES(K, 2) || AES(K, 3)\\
&K_{MAC}^2 = AES(K, 4) || AES(K, 5)
\end{align*}

Here we assume that AES is a secure PRP and by the property of PRPs, all above 
keys are pseudorandom, and hence indistinguishable from random strings via an 
efficient adversary. Note that we do not need to store these keys, as they can 
all be derived from $K$.

We also do care about message padding in this case. Namely, if the message is 
not a multiple of the block length, we pad it with $100..0$ at the end or if the 
message is a multiple of the block length, we add a dummy block $100..0$.

As was described in class, CBC-MAC is secure only if the key is used less then 
${|X|}^{1/2}$ times, where $|X|$ is the size of the block. In our case, since we 
are using AES that has 128-bit long blocks, we need to update the keys after 
they've been used for $2^{64}$ times, but we will assume that we will not send 
more than $2^{64}$ messages.

\section{Using MAC to authenticate messages}

To build a MAC for the message we just use the scheme described above for our 
message and we use the group key for $K$. If the MAC did not pass the 
verification, we output~--- "Decryption failed" and we "drop the cipher on the 
floor", making no attempt to decrypt it.

\section{Database encryption}

For database encryption in Milestone1 we derived a 256bit long key ($K_{pass}$) 
from the user's password, outputting some extra information called the "salt", 
to be able to reconstruct this key. For encrypting now we are using the key 
derived from $K_{pass}$ as described above, instead of $K_{pass}$ itself.
We encrypt the database, then append salt and then MAC the result.

If MAC verification failed, we show an alert box saying so.

\end{document}
